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(54) Service delivery method and system 

(57) A user is p re-qualified for a service to be pro- 
vided at a particular location. A service token (80) is 
stored as is location data (74) indicative of where the 
service is to be triggered; the service token (80) is stored 
in a mobile entity (20) associated with the user There- 



after, the location of the user, as indicated by the location 
of the mobile entity (20), is periodically checked against 
the location data (74) and when a location match is in- 
dicated, the service token (80) is passed to a service 
provider system to trigger delivery of the service for 
which the user has been qualified. 
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Description 

Field of the Invention 

[0001 J The present Invention relates to the delivery of 
services to mobile users in dependence on the location 
of the users. 

Background of the Invention 

[0002] Communication infrastructures suitable for 
mobile users (in particular, though not exclusively, cel- 
lular radio infrastructures) have now become widely 
adopted. Whilst the primary driver has been mobile te- 
lephony, the desire to implement mobile data-based 
services over these infrastructures, has led to the rapid 
development of data -capable bearer services across 
such infrastructures. This has opened up the possibility 
of many Internet-based services being available to mo- 
bile users. 

[0003] By way of example, Figure 1 shows one form 
of known communication infrastructure for mobile users 
providing both telephony and data-bearer services. In 
this example, a mobile entity 20, provided with a radio 
subsystem 22 and a phone subsystem 23, communi- 
cates with the fixed infrastructure of GSM PLMN (Public 
Land Mobile Network) 1 0 to provide basic voice teleph- 
ony services. In addition, the mobile entity 20 includes 
a data- handling subsystem 25 interworking, via data in- 
terface 24 , with the radio subsystem 22 for the transmis- 
sion and reception of data over a data-capable bearer 
service provided by the PLMN; the data-capable bearer 
service enables the mobile entity 20 to communicate 
with a service system 40 connected to the public Internet 
39. The data handling subsystem 25 supports an oper- 
ating environment 26 in which applications run, the op- 
erating environment including an appropriate communi- 
cations stack. 

[0004] More particularly, the fixed infrastructure 10 of 
the GSM PLMN comprises one or more Base Station 
Subsystems (BSS) 11 and a Network and Switching 
Subsystem NSS 12. Each BSS 11 comprises a Base 
Station Controller (BSC) 14 controlling multiple Base 
Transceiver Stations (BTS) 13 each associated with a 
respective -cell" of the radio network. When active, the 
radio subsystem 22 of the mobile entity 20 communi- 
cates via a radio link with the BTS 13 of the cell in which 
the mobile entity is currently located. As regards the 
NSS 12, this comprises one or more Mobile Switching 
Centers (MSC) 15 together with other elements such as 
Visitor Location Registers 32 and Home Location Reg- 
ister 32. 

[0005] When the mobile entity 20 is used to make a 
normal telephone call, a traffic circuit for carrying digi- 
tised voice is set up through the relevant BSS 11 to the 
NSS 12 which Is then responsible for routing the call to 
the target phone (whether in the same PLMN or in an- 
other network). 



[0006] With respect to data transmission to/from the 
mobile entity 20, in the present example three different 
data-capable bearer services are depicted though other 
possibilities exist. A first data-capable bearer service is 

5 available in the form of a Circuit Switched Data (CSD) 
service; in this case a full traffic circuit is used for carry- 
ing data and the MSC 32 routes the circuit to an Inter- 
Working Function IWF 34 the precise nature of which 
depends on what is connected to the other side of the 

*0 IWF. Thus, IWF could be configured to provide direct 
access to the public Internet 39 (that is, provide func- 
tionality similar to an IAP - Internet Access Provider 
IAP). Alternatively, the IWF could simply be a modem 
connecting to a PSTN; in this case, Internet access can 

15 be achieved by connection across the PSTN to a stand- 
ard IAP. 

[0007] A second, low bandwidth, data-capable bearer 
service Is available through use of the Short Message 
Service that passes data carried In signalling channel 

20 slots to an SMS unit which can be arranged to provide 
connectivity to the public Internet 39. 
[0008] A third data-capable bearer service is provided 
in the form of GPRS ^General Packet Radio Service 
which enables IP (or X.25) packet data to be passed 

2s from the data handling system of the mobile entity 20, 
via the data interface 24, radio subsystem 21 and rele- 
vant BSS 11, to a GPRS network 17 of the PLMN 10 
(and vice versa). The GPRS network 1 7 includes a SG- 
SN (Serving GPRS Support Node) 18 interfacing BSC 

30 14 with the network 17, and a GGSN (Gateway GPRS 
Support Node) interfacing the network 1 7 with an exter- 
nal network (in this example, the pub lie Internet 39); Full 
details of GPRS can be found In the ETSI (European 
Telecommunications Standards Institute) GSM 03.60 

35 specification. Using GPRS, the mobile entity 20 can ex- 
change packet data via the BSS 11 and GPRS network 
17 with entities connected to the public Internet 39. 
[0009] The data connection between the PLMN 10 
and the Internet 39 wQI generally be through a firewall 

40 35 with proxy and/or gateway functionality. 

[0010] Different data-capable bearer services to 
those described above may be provided, the described 
services being simply examples of what is possible. 
[0011] In Figure 1 , a service system 40 is shown con- 

*3 nected to the Internet 40, this service system being ac- 
cessible to the OS/application 26 running In the mobile 
entity by use of any of the data-capable bearer services 
described above. The data-capable bearer services 
could equally provide access to a service system that is 

so within the domain of the PLMN operator or is conn ected 
to another public or private data network. 
[0012] With regard to the OS/application software 26 
running in the data handling subsystem 25 of the mobile 
entity 20, this could, for example, be a WAP application 

ss running on top of a WAP stack where "WAP* is the Wire- 
less Application Protocol standard. Details of WAP can 
be found, for example, in the book "Official Wireless Ap- 
plication Protocol" Wireless Application Protocol Forum. 
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Ltd published 1993 Wiley Computer Publishing. Where 
the OS/application software is WAP compliant, the fire- 
wall will generally also serve as a WAP proxy and gate- 
way. Of course, OS/application 26 can comprise other 
functionality (for example, an e-mail client) instead of, 
or additional to. the WAP functionality. 
[0013] The mobile entity 20 may take many different 
forms. For example, it could be two separate units such 
as a mobile phone (providing elements 22-24) and a mo- 
bile PC (data- handling system 25) coupled by an appro- 
priate link (wireline, infrared or even short range radio 
system such as Bluetooth). Alternatively, mobile entity 
20 could be a single unit such as a mobile phone with 
WAP functionality. Of course, if only data transmission/ 
reception is required (and not voice), the phone func- 
tionality 24 can be omitted; an example of this is a PDA 
with built-in GSM data-capable functionality whilst an- 
other example is a digital camera (the data-handling 
subsystem) also with built-in GSM dala-capable func- 
tionality enabling the upload of digital images from the 
camera to a storage server. 

[0014] Whilst the above description has been given 
with reference to a PLMN based on GSM technology, it 
will be appreciated that many other cellular radio tech- 
nologies exist and can typically provide the same type 
of functionality as described for the GSM PLMN 10. 
[001 5] Recently, much interest has been shown in "lo- 
cation-based" , "location-dependent", or "location- 
aware* services for mobile users, these being services 
that take account of the current location of the user (or 
other mobile party). The most basic form of this service 
is the emergency location service whereby a user in 
trouble can press a panic button on their mobile phone 
to send an emergency request-for-assistance message 
with their location data appended. Another well known 
location-based service is the provision of traffic and 
route-guiding information to vehicle drivers based on 
their current position. A further known service is a "yel- 
low pages" service where a user can find out about 
amenities (shops, restaurants, theatres, etc.) local to 
their current location. The term "location -aware servic- 
es" will be used herein to refer generically to these and 
similar services where a location dependency exists. 
[0016] Location-aware services all require user loca- 
tion as an input parameter. A number of methods al- 
ready exist for determining the location of a mobile user 
as represented by an associated mobile equipment. Ex- 
ample location-determining methods will now be de- 
scribed with reference to Figures 2 to 5. As will be seen, 
some of these methods result in the user knowing their 
location thereby enabling them to transmit it to a loca- 
tion-aware service they arc interested in receiving, 
whilst other of the methods result in the user's location 
becoming known to a network entity from where it can 
be supplied directly to a location-aware service (gener- 
ally only with the consent of the user concerned). It is to 
be understood that additional methods to those illustrat- 
ed in Figures 2 to 5 exist. 



[0017] As well as location determination, Figures 2 to 
5 also illustrate how the mobile entity requests a loca- 
tion- aware service provided by service system 40. In the 
present examples, the request is depicted as being 
5 passed over a cellular mobile network {PLMN 10) to the 
service system 40. The PLMN is, for example, similar to 
that depicted in Figure 1 with the service request being 
made using a data-capable bearer service of the PLMN. 
The service system 40 may be part of the PLMN Itself 
10 or connected to it through a data network such as the 
public Internet. It should, however, be understood that 
infrastructure other than a cellular network may alterna- 
tively be used for making the service request 
[0018] The location-determining method illustrated in 
is Figure 2 uses an inertial positioning system 50 provided 
in the mobile entity 20A, this system 50 determining the 
displacement of the mobile entity from an initial refer- 
ence position. When the mobile entity 20A wishes to in- 
voke a local ion -aware service, it passes its current po- 
^0 srtion to the corresponding service system 40 along with 
the service request 51 . This approach avoids the need 
for an infrastructure to provide an external frame of ref- 
erence; however, cost, size and long-term accuracy 
concerns currently make such systems unattractive for 
*5 incorporation into mass-market handheld devices. 

[0019] Figure 3 shows two different location-deter- 
mining methods both involving the use of local, fixed- 
position, beacons here shown as infra-red beacons IRD 
though other technologies, such as short-range radio 
30 systems (in particular, "Bluetooth" systems) may equally 
be used. The right hand half of Figure 3 show a number 
of independent beacons 55 that continually transmit 
their individual locations. Mobile entity 20B is arranged 
to pick up the transmissions from a beacon when suffi- 
ss ciently close, thereby establishing its position to the ac- 
curacy of its range of reception. This location data can 
then be appended to a request 59 made by the mobile 
entity 20 B to a location-aware service available from 
service system 40. A variation on this arrangement is 
40 for the beacons 55 to transmit information which whilst 
not directly location data, can be used to look up such 
data (for example, the data maybe the Internet home 
page URL of a store housing the beacon 55 concerned, 
this home page giving the store location - or at least 
43 identity, thereby enabling look-up of location in a direc- 
tory service). 

[0020] In the left-hand half of Figure 3, the IRB bea- 
cons 54 are all connected to a network that connects to 
a location server 57. The beacons 54 transmit a pres- 

so ence signal and when mobile entity 20C is sufficiently 
close to a beacon to pick up the presence signal, it re- 
sponds by sending its identity to the beacon. (Thus, in 
this embodiment, both the beacons 54 and mobile entity 
20C can both receive and transmit IR signals whereas 

55 beacons 55 only transmit, and mobile entity 20 B only 
receives, IR signals). Upon a beacon 54 receiving a mo- 
bile entity's identity, it sends out a message over network 
56 to location server 57, this message linking the identity 
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of the mobile entity 20C to the location of the relevant 
beacon 54. Now when the mobile entity wishes to invoke 
a location -aware service provided by the service system 
40, since it does not know its location it must include ifs 
identity in the service request 58 and rely on the service 
system 40 to look up the current location of the mobile 
entity in the location server 57. Because location data 
is personal and potentially very sensitive, the location 
server 57 will generally only supply location data to the 
service system 40 after the latter has produced an au- 
thorizing token supplied by the mobile entity 208 in re- 
quest 58. It will be appreciated that whilst service system 
40 is depicted as handling service requests form both 
types of mobile entity 20 8 and 20C, separate systems 
40 may be provided for each mobile type (this is likewise 
true in respect of the service systems depicted in Fig- 
ures 4 and 5). 

[0021] Figure 4 depicts several forms of GPS loca- 
tion-deiermining system. On the left-hand side of Figure 
4, a mobile entity 20D is provided with a standard GPS 
module and is capable of determining the location of en- 
tity 20D by picking up signals from satellites 60. The en- 
tity 20D can then supply this location when requesting, 
in request 61 , a location -aware service from service sys- 
tem 40. 

[0022] The right-hand side of Figure 4 depicts, in re- 
lation to mobile entity 20E, two ways in which assistance 
can be provided to the entity in deriving location from 
GPS satellites. Firstly, the PLMN 10 can be provided 
..with fixed GPS receivers 62 that each continuously keep 
track of the satellites 60 visible from the receiver and 
pass information in messages 63 to local mobile entities 
20E as to where to look for these satellites and estimat- 
ed signal arrival times; this enables the mobile entities 
20E to substantially reduce acquisition time for the sat- 
ellites and increase accuracy of measurement (see n Ge- 
olocation Technology Pinpoints Wireless 911 calls with- 
in 15 Feet" 1-Jul-99 Lucent Technologies, Bell Labs). 
Secondly, as an alternative enhancement, the process- 
ing load on the mobile entity 20E can be reduced and 
encoded jitter removed using the services of network 
entity 64 (in or accessible through PLMN 10). 
[0023] One the mobile unit 20E has determined its lo- 
cation, it can pass this information in request 65 when 
invoking a location-aware service provided by service 
system 40. 

[0024] Figure 5 depicts two general approaches to lo- 
cation determination from signals present in a cellular 
radio infrastructure. First, it can be noted that in general 
both the mobile entity and the network will know the 
identity of the cell in which the mobile entity currently 
resides, this information being provided as part of the 
normal operation of the system. (Although in a system 
such as GSM, the network may only store current loca- 
tion to a resolution of a collection of cells known as a 
"location area", the actual current cell 10 will generally 
be derivable from monitoring the signals exchanged be- 
tween the BSC 14 and the mobile entity). Beyond cur- 



rent basic cell ID, it is possible to get a more accurate 
fix by measuring timing and/or directional parameters 
between the mobile entity and multiple BTSs 13. these 
measurement being done either in the network or the 

5 mobile entity (see, for example, International Applica- 
tion WO 99/04582 that describes various techniques for 
effecting location determination in the mobile and WO 
99755114 that describes location determination by the 
mobile network in response to requests made by loca- 

10 tion-aware applications to a mobile location center - 
server- of the mobile network). 

[0025] The left-hand half of Figure 5 depicts the case 
of location determination being done in the mobile entity 
20F by, for example, making Observed Time Difference 
15 (OTD) measurements with respect to signals from BTSs 
13 and calculating location using a knowledge of BTS 
locations. The location data is subsequently appended 
to a service request 66 sent to service system 40 In re- 
spect of a location-aware service. The calculation load 

20 on mobile entity 20F could be reduced and the need for 
the mobile to know BTS locations avoided, by having a 
network entity do some of the work. The right-hand half 
of Figure 5 depicts the case of location determination 
being dono in the network, for example, by making Tim- 

25 ing Advance measurements for three BTSs 13 and us- 
ing these measurements to derive location (this deriva- 
tion typically being done In a unit associated with BSC 
14). The resultant location data is passed to a location 
server 67 from where it can be made available to au- 

.30 _thorised services. As for the mobile entity 20C in Figure 
3, when the mobile entity 20G of Figure 5 wishes to in- 
voke a location -aware service available on service sys- 
tem 50, it sends a request 69 including an authorisation 
token and its ID (possible embedded in the token) to the 

35 service system 40; the service system then uses the au- 
thorisation token to obtain the current location of the mo- 
bile entity 20G from the location server 67. 
[0026] In the above examples, where the mobile entity 
is responsible for determining location, this will generally 

^0 be done only at the time the location-aware service is 
being requested. Where location determination is done 
by the infrastructure, it may be practical for systems cov- 
ering only a limited n umber of users (such as the system 
illustrated in the left-hand half of Figure 2 where a 

^5 number of Infrared beacons 54 will cover a generally 
fairly limited) for location-data collection to be done 
whenever a mobile entity is newly detected by an IRB, 
this data being passed to location server 57 where it is 
cached for use when needed. However, for systems 

so covering large areas with potentially a large number of 
mobile entities, such as the Figure 5 system, it is more 
efficient to effect location determination as and when 
there is a perceived need to do so; thus, location deter- 
mination may be triggered by the location server 67 in 

55 response to the service request 68 from the mobile en- 
tity 20G or the mobile entity may, immediately prior to 
making request 68, directly trigger BSC 14 to effect a 
location determination and feed the result to location 
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server 67. 

[0027] Further with respect to the location servers 57, 
67, whilst access authorisation by location -aware serv- 
ices has been described as being through authorisation 
tokens supplied by the mobile entities concerned, other 
authorisation techniques can be used. In particular, a 
location-aware service can be prior authorised with the 
location server in respect of particular mobile entities; in 
this case, each request from the service for location data 
needs only to establish that the request comes from a 
service authorised in respect of the mobile entity for 
which the location data is requested. 
[0028] As already indicated, Figures 2 to 5 depict only 
some examples of how location determination can be 
achieved, there being many other possible combina- 
tions of technology used and where in the system the 
location-determining measurements are made and lo- 
cation is calculated, stored and used Thus, the loca- 
lion-aware service may reside in the mobile entity 
whose location is of interest, in a network-connected 
service system 40 (as illustrated), or even in another 
mobile entity. Furthermore, whilst in the examples of 
Figures 2 to 5 S invocation of the location-aware service 
has been by the mobile entity whose location is of inter- 
est, the nature of the location -aware service maybe 
such that it is invoked by another party (including, po- 
tentially, the PLMN itself). In this case, unless the invok- 
ing party already knows the location of he mobile entity 
and can pass this information to the location-aware 
service (which may, for example, may be situation 
where the PLMN invokes the service), it is the location- 
aware service that is responsible for obtaining the re- 
quired location data, either by sending a request to the 
mobile entity itself or by requesting the data from a lo- 
cation server. Unless the location server already has the 
needed information in cache, the server proceeds to ob- 
tain the data either by interrogating the mobile entity or 
by triggering infrastructure elements to locate the mo- 
bile. For example, where a location-aware service run- 
ning on service system 40 in Figure 5 needs to find the 
location of mobile 20G, it could be arranged to do so by 
requesting this information from location server 67 
which inturn requests the location data from the relevant 
BSC, the latter then making the necessary determina- 
tion using measurements from BTSs 13. 
[0029] Although in the foregoing, the provision of lo- 
cation data through the mobile radio infrastructure to the 
mobile entity has been treated as a service effected over 
a data-capable bearer channel, it may be expected that 
as location data becomes considered a basic element 
of mobile radio infrastructure services, provision will be 
made in the relevant mobile radio standards for location 
data to be passed over a signalling channel to the mobile 
entity. 

[0030] US 6 : 01 1 ,973 discloses a mobile phone that is 
arranged to be enabled or disabled according to its lo- 
cation, data about the allowability of operation of the mo- 
bile phone in various geographical locations being 
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stored either in the phone or elsewhere. WO-A- 
97/41654 describes the location-based triggering of in- 
formation services to registered customers. US 
5,568,153 discloses a system where the parameters of 

5 a service are determined on the basis of the user's cur- 
rent location, this being done after service delivery is 
requested. WO-A- 9 9/67904 describes paying for an 
electronic access key to an event, the key being stored 
in a handset until required. US 6,236,981 discloses an 

10 arrangement where tokens are stored in a Carnet and 
spent by transfer to an on-line merchant. 
[0031] It is an object of the present invention to pro- 
vide an improved method and system for service deliv- 
ery to mobile users. 

15 

Summary of the Invention 

[0032] According to one aspect of the present inven- 
tion, there is provided a service delivery method com- 
20 prising the steps of: 

qualifying a user as authorised to benefit from a par- 
ticular service, and thereupon storing: 

2S - location data indicative of at least one location 
where service delivery is to be triggered, and 
a service token for said particular service, 

the service token being stored in a mobile entity as- 

-30 sociated with the user; and 

subsequently detecting a location match between 
the location of the user, as indicated by the location 
of said mobile entity, and a location indicated by 
said location data, and thereupon passing the serv- 
35 ice token from the mobile entity to a service provider 
system to initiate delivery to the user of said partic- 
ular service. 

[0033] According to another aspect of the present in- 
*o vention, there is provided a service delivery system 
comprising: 

a mobile entity associated with a user; 

a location-description repository for storing location 

*5 data; 

a service-token repository, incorporated into said 
mobile entity, for storing at least one service token; 
a qualification subsystem for determining whether 
said user qualifies to benefit from an instance of a 

50 particular service, the qualification subsystem be- 
ing operative, upon determining that a user is so 
qualified, both to store in the location repository lo- 
cation data indicative of at least one location where 
service delivery is to be triggered, and also to store 

55 jn the service-token repository a service token for 
said particular service; 

a service delivery subsystem for providing said par- 
ticular service, the service delivery subsystem be- 
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ing separate from said mobile entity; 
a communications arrangement for enabling the 
mobile entity to communicate with the service de- 
livery subsystem; 

a location-match subsystem for detecting a location 
match between the location of the user, as indicated 
by the location of said mobile entity, and a location 
indicated by said location data; and 
a control arrangement responsive to the location- 
match subsystem detecting a said location match 
to cause the mobile entity to pass the service token 
to the service delivery subsystem to initiate delivery 
of said particular service to the user. 

Brief Description of the Drawings 

[0034] A service delivery method and system, both 
embodying the present invention, will now be described, 
by way of non-limiting example, with reference to the 
accompanying diagrammatic drawings, in which: 

. Figure 1 is a diagram of a known communications 
infrastructure usable for transferring 
voice and data to/from a mobile entity; 

. Figure 2 is a diagram illustrating one known ap- 
proach to determining the location of a 
mobile entity, this approach involving 
providing the entity with an inertia! posi- 
tioning system; 

.Figure 3 is a diagram Illustrating another known 
approach to determining the location of 
a mobile entity, this approach being 
based on proximity of the mobile entity 
to fixed -position local beacons; 

. Figure 4 is a diagram illustrating a further known 
approach to determining the location of 
a mobile entity, this approach involving 
the use of GPS satellites; 

. Figure 5 is a diagram illustrating a stiil further ap- 
proach to determining the location of a 
mobile entity, this approach being based 
on the use of signals present in a cellular 
mobile radio communications system; 

. Figure 6 is a diagram illustrating the main logical 
components of a service delivery meth- 
od and system embodying the invention; 

. Figure 7 is a diagram illustrating a first specific 
embodiment of the invention; 

. Figure 8 is a diagram illustrating a second specific 
embodiment; 

. Figure 9 is a diagram illustrating a third specific 

embodiment; and 
. Figure 10 is a diagram illustrating a fourth specific 

embodiment. 

Best Mode of Carrying Out the Invention 

[0035] Service delivery methods and systems em- 
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bodying the invention will now be described with refer- 
ence to Figures 6 to 10. The specific embodiments of 
Figures 7 to 10 depict a user with a cellular mobile de- 
vice and a mobile infrastructure with a location server 
for providing location data about mobile users; the spe- 
cific embodiments shown in Figures 7 to 9 also depict a 
service system 40 connected to the public Internet 39. 
It is to be understood that the present invention is not 
limited to the specifics of the mobile entity, location dis- 
covery means or communication infrastructure shown 
in the Figures and the generalisations discussed above 
in relation to Figures 1 to 5 regarding these elements 
apply equally to the operational context of the described 
embodiments of the invention. Thus, whilst the service 
system 40 in Figures 7 to 9 is shown as connected to 
the public Internet, it could be connected to a<3PRS net- 
work 1 7 or to another fixed data network Interfacing di- 
rectly or Indirectly with the network 17 or network 39. 
Furthermore, communication between the user's mobile 
entity and a service system can be via a communication 
infrastructure that does not use cellular radio; for exam- 
ple, a short-range wireless system could be used. 
[0036] Consideration will first be given to the gener- 
alised embodiment of the service delivery method 
shown in Figure 6. In Figure 6 a user entity 70 is depicted 
which comprises a user and a mobile device through 
which the location of the user can be ascertained (for 
example, a mobile entity 20 such as shown in Figures 
2 to 5). For convenience, the term "user entity" will be 
-used both for act ions/events involving only the device 
itself and actions/events involving the user acting 
through the mobile device; the reference 70 will be used 
both for the user entity and for the user alone. 

[1] - When the user 70 subscribes to a service or 
buys a product with which a service is associated, 
the service seller, acting through a service factory 
client 71 , causes an executable service instance 76 
to be created by a service factory 72 associated with 
the service. The service instance is an embodiment 
of the behavior associated with the purchased serv- 
ice. The service instance is associated with a set of 
weil-defined locations that are of interest to the 
service. These locations are specified in location 
descriptors 74 that either specify locations or polyg- 
onal areas, either as a set of x,y coordinates, or as 
a set of high-level semantic representations such 
as "Lloyds Bank, Bristol" that can be mapped to 
physical locations. Each user has a Service Repos- 
itory 75 to hold the current set of service instances 
76 active for the user's context. The Location De- 
scriptors 74 associated with the service instances 
of the user are held in a Location Descriptor Repos- 
itory 73. 

[2] - The newly created service instance 76 and an 
initial set of one or more location descriptors 74 lo 
be applied to the service, are downloaded respec- 
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tively to the Service Repository 75 and Location De- 
scriptor Repository 73 of the user. The service re- 
mains dormant until the location of the user entity 
70 matches one of the locations defined by the Lo- 
cation Descriptors defined for the service. 

[3] - The physical location of the user entity 70 is 
obtained by a location source 77 In any suitable 
manner and passed on a periodic basis to a Loca- 
tion Comparator Engine 78. 

[4] - The Location Comparator Engine 78 compares 
the current location of entity 70 with the set of active 
Location Descriptors 74. If a match is found, a trig- 
ger is sent to a Service Execution Environment 79, 
this trigger identifying the service instance to be ex- 
ecuted (for example, by combination of user ID and 
location, or by a service instance identifier held with 
the matched Location Descriptor) 

[5] - the Service Execution Environment 79 loads 
the appropriate service instance 76 and executes 
it, passing in the current location if required. The 
service may be one that once triggered, runs to 
completion regardless of subsequent changes in lo- 
cation, or one that only functions whilst the location 
matches a location descriptor. In this latter case, lo- 
cation samples are taken at intervals and the serv- 
ice only continues to run for as long as the current 
— location matches the Location Descriptors of the 
service. 

[61 - The service can be enabled to specify the fre- 
quency of location updates it requires, and also 
modify the set of Location Descriptors 74 to be ap- 
plied. 

[0037] The physical location of the functional entities 
71 , 72, 73, 75, 77, 78 and 79 depends on the architec- 
ture of the network infrastructure used to inter-commu- 
nicate the entities and the capabilities of the mobile de- 
vice of user entity 70. Thus, whilst the Service Factory 
72 will generally be located in the network infrastructure, 
each of the other entities could be located either on the 
mobile device or in the network. 

[0038] A possible service delivery scenario Is as fol- 
lows. A customer buys an airline flight ticket. A service 
instance 76 is instantiated by the airline to identify the 
specific purchasing transaction, so that the behavior of 
the service instance can be made dependent on char- 
acteristics of the transaction. A description of the loca- 
tion trigger point(s) of the service is stored either in the 
user's mobile device (e.g. a cell-phone device) or in the 
cellular radio infrastructure. Assume that a trigger point 
is the airport. When the customer arrives at the airport, 
the location of the mobile device as determined by the 
cellular radio infrastructure matches the trigger point of 
the service. The service instance is now activated, can 



welcome the customer by name, politely ask them to 
check in, invite and direct the customer to airline lounge 
if the customers ticket is of the appropriate type, and 
finally remind the customer to leave the lounge when 

5 the flight is boarding. 

[0039] In the Figure 6 embodiment, a full executable 
service instance is created by the service factory. This 
is particularly useful where the service execution envi- 
ronment is either the mobile device or another system 

io which does not have large resources or continual net- 
work access. An alternative approach is to store in- 
stance customization data that can be used to custom- 
ize generalized service code that is available to the serv- 
ice execution environment either because the latter has 

15 resources to store such code or can access the code 
across a network connection. 

[0040] Thus, in general terms, the service factory, 
once it is satisfied that the user has qual if led for the serv- 
ice (for example, by having paid or by having appropri- 
ate ate attributes), generates a service instance element 
that associates the user with an instance of the service 
for which the user has been qualified. The service in- 
stance element can be a full executable code version of 
tho service as described above in relation to Figure 6, 
25 customization data customizing a generalized service 
to the user, or even just an indicator that the user is en- 
titled to the benefits of a service instance which is not 
otherwise subject to customization. 
[0041] A number of different ways can be used by the 
30 service instance element to associate the user and the 
service instance for which the user has been qualified.. 
One way is to have the service instance element contain 
an identifier of the user, the instance element either itself 
including the instance executable or including a refer- 
as ence to the latter; in this case, the location trigger proc- 
ess results in the user identifier being produced for 
matching up with the service instance element (note that 
if multiple service instance elements are stored for the 
same user, additional information such as triggering lo- 
«o cation, may be required to distinguish between the serv- 
ice instance elements). Another way is to include a serv- 
ice instance identifier in the service instance element, 
this identifier also being associated with the user (for 
example, by being known to the user entity) and being 
43 produced by the location trigger process for matching 
with the service instance element. A third way of having 
the service instance element associaLe a user with a 
particular service instance is to store the service in- 
stance element in the user entity or other user-dedicated 
so entity. 

[0042] With regard to the location triggering process, 
it will be appreciated that this can be implemented in 
many ways. For example, the location descriptors can 
be stored in a service system containing the service ex- 
55 ecution environment, the user's current location being 
provided to the service system by a location server 
(such as server 57 of Figure 3 or server 67 of PLMN 10 
of Figure 5) or by the user entity 70 itself {the entity 70 
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having discovered its location by any of the methods de- 
picted in Figures 2 to 5, for example). Alternatively, the 
location descriptors could be stored in a location server 
57 or 67 with location matching also being effected in 
the server. Another possibility is to store the location de- s 
scriptors in the user entity 70 itself, the latter discovering 
its location by a method of Figures 2 to 5 and effecting 
the location matching process itself. 
[0043] Specific example embodiments will now be de- 
scribed with reference to Figures 7 to 10. u> 
[0044] In the Figure 7 embodiment, the service factory 
has loaded a service instance element (SIE) 80 into a 
database 75 of a service delivery system 40 and a cor- 
responding location descriptor 74 into a repository 73 
associated with location server 67 of PLMN 1 0. The SIE « 
80 comprises, in this example, a user identifier (user ID) 
and user-specific customization data. The location de- 
scriptor 74 also includes the user ID and the location 
server 67 of PLMN understands which PLMN subscriber 
is identified by this user ID (conveniently, the user ID 20 
can be the IM SI associated with the user). Service sys- 
tem 40 comprises, as well as database 75, a program 
database 81 holding the generic program code for the 
services to be delivered by the system, a service exe- 
cution environment 78, a service loader 82 for loading 25 
the correct service program and customization data to 
provide a required service instance, and interface 41 for 
interfacing the service system with a communication in- 
frastructure (here shown as internet 39). 
[0045] — The user's mobile device is a cellular-radio mo- -30 
bile entity 20 such as described with reference to Figure 
1 and is capable of communicating with the service sys- 
tem 40 via a data-capable bearer service of PLMN 10 
and internet 39. When the mobile entity is in a switched- 
on state, location server 67 of PLMN 10 is capable of 35 
determining the location of the mobile entity. 
[0046] In operation, upon the mobile entity 20 being 
detected by location server 67 as at a location matching 
a location descriptor 74 associated with the user, a lo- 
cation match trigger (including user ID and possibly also *o 
user location) is passed from the location server 67 to 
the service loader 82 of the service system 40 (see ar- 
row B5). The service loader uses the user ID (and pos- 
sibly also the user location) to identify the corresponding 
SIE 80. The SIE 80 identifies the service program to be *5 
executed and service loader 82 causes the relevant pro- 
gram to be loaded into the service execution environ- 
ment along with the customization data contained in the 
SIE 80 in order to create and run the service instance 
for which the user has been prior authorized. Execution so 
of the service instance will generally (but not necessar- 
ily) involve communication between the service system 
and the user's mobile entity 20, for example using a da- 
ta-capable bearer service of PLMN 10 (see arrow 86). 
[0047] The Figure 8 embodiment is similar to that of ss 
Figure 7 except that now the location descriptors 74 are 
stored in mobile entity 20, each with an associated serv- 
ice instance identifier (SI ID), and the SlEs 80 stored in 



database 75 each include a corresponding SI ID. Loca- 
tion matching between the location descriptors and the 
user's current location (as identified to the entity 20 by 
location server 67 or discovered in some other way) is 
done in the mobile entity 20. When a match is detected, 
the SI ID associated with the matched location is passed 
to the service loader 82 (see arrow 87) which looks up 
the corresponding SIE 80 in database 75 and then over- 
sees running of the appropriate service instance. If re- 
quired, the SIE 80 can include both the user ID and the 
locations where the service instance is permitted to be 
triggered; the service loader can then be arranged to 
confirm (and possibly even require authentication of) the 
user's identity and the origin of the user's location fix 
(the service instance may, for example, require that only 
location fixes by location server 67 will be trusted, in 
which case the mobile entity 20 can be required to pro- 
vide digitally-signed location data from the server 67). 
[0048] In the Figure 9 embodiment, the location de- 
scriptors 74 are again stored in the mobile entity 20 
where location matching is effected. However, now the 
SIE 80 is also stored in the mobile entity 20 and takes 
the form of a service token that can be used to claim 
service instance delivery from a service system 40. Tho 
service token is associated with the user by virtue of be- 
ing stored in the mobile entity 20 and includes data iden- 
tifying the service to be provided by service system 40 
and any service customization data; advantageously, 
the service token also includes address (and password) 
details for contacting the service system. In operation, 
upon a location match being detected, the mobile entity 
transits the service token, via a data-capable bearer 
service of PLMN 10 and the internet 39, to the service 
system. At the service system, the token is passed to 
an authentication and service execution subsystem 83 
where it is used to instantiate and run the required serv- 
ice instance. 

[0049] Preferably, the service token includes the us- 
er's identity and is digitally signed by the service factory 
(with a corresponding certificate being included in the 
token). In this case, the sub-system 83 can both: 

check that the service token originates from a serv- 
ice factory for which it is willing to provide service 
delivery (this check involves checking the identity 
of the signing party with the certification authority In 
standard manner); and 

check that the parly sending the token is the same 
as the party identified in the token (the authenticity 
of which is guaranteed by the digital signature). 
Checking the sending party's identity is done using 
a challenge / response mechanism by which the 
service system 40 sends an item of data to the mo- 
bile entity and asks it to return it signed/encrypted 
under its private key (it being assumed that the mo- 
bile entity is provided with a public key / private key 
pairthat are associated with the user). This enables 
the service system to check the identity of the user 
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(with the user's certificate Authority) and thus check 
whether the user is the same party as identified In 
the token. 

[0050] Of course, since the basic challenge/response 
mechanism is something that is normally done between 
the system 40 and the mobile entity 20 without involve- 
ment of the user, the mechanism does not guard against 
the mobile entity having been stolen. As an added pre- 
caution, therefore, the user authentication process pref- 
erably further includes asking forthe user to input a PIN 
number, this latter being known to the system 40 (such 
as by having been included in the token, possibly en- 
crypted in a manner enabling only the service system 
40 to decrypt It - for example, tne service factory en- 
crypis the PIN using the public key of the service system 
40). 

[0051] It will be appreciated that the same authenti- 
cation process can equally be applied in full or in part to 
the case where the service token is replaced by a fully 
executable service instance code. 
[0052] In the Figure 10 embodiment the location de- 
scriptors 74 are again stored in the mobile entity 20 
where location matching is effected. However, now the 
SIE 80 comprises the full service instance executable 
76 stored in the mobile entity 20 and intended to execute 
in the mobile entity when a location match is detected. 
No external interaction with a pre-authorised service el- 
ement is required. Of course, external service interac- 
tions can-be-effected during the course of service exe- 
cution (though not shown In Figure 10). As already not- 
ed, the current location of the mobile entity can be pro- 
vided by means other than the location server 67 of 
PLMN 10, for example by a built-in GPS system or from 
local location beacons, and in this case, wide-area con- 
nectivity is not required for mobile entity 20. 

Variants 

[0053] It will be appreciated that many variants are 
possible with respect to the above described embodi- 
ments with features described in relation to one embod- 
iment also being adaptable for use with other of the em- 
bodiments. Thus, for example, the authentication fea- 
tures (digital signing of SIE 80 to check origin, user au- 
thentication through challenge/response mechanism, 
use of PIN) described above in relation to the Figure 9 
embodiment can also be used with the other embodi- 
ments. For example, where the SIE 80 is distributed by 
the service factory to a device or system under different 
control, it will generally be a good practice to have the 
S IE digitally signed by the service factory so as to enable 
the final service delivery system (system 40 in Figures 
7 to 9) to check the origin of the SIE BO. Again, checking 
the identity of the user requesting service execution will 
often also be prudent, using a challenge/response 
mechanism and/or PIN input. 

[0054] As noted above, the mobile entity 20 need not 



have wide-area connectivity. For example, communica- 
tion with service system 40 could be through a short 
range wireless link (for example, an infra-red link or a 
Bluetooth radio connection). In fact, as already indicated 

5 with respect to the Figure 10 embodiment, the mobile 
entity 20 need not have any external communication ca- 
pability other than to enable it to determine its location. 
[0055] The location descriptors and service instances 
elements can be stored by user, by service to be dellv- 

*o ered, or in any other suitable distribution. For example, 
where different service systems 40 are used for different 
services in the embodiments of Figures 7 and 8 embod- 
iments, then the database 75 of each service system 40 
will store SIEs 80 relating to different users but the same 

'5 service. 

[0056] A service instance element can be arranged to 
specify a particular number of times (including only 
once) that the associated service instance can be run, 
each running of Ihe service instance decrementing this 
20 count (or incrementing a count of the number of times 
the instance has been run). 



Claims 

25 

1. A service delivery method comprising the steps of: 

qualifying a user (70) as authorised to benefit 
from a particular service, and thereupon storing 
-30-.- (J2]): 

location data (74) indicative of at least one 
location where service delivery is to be trig- 
gered, and 

35 - a service token (80) for said particular serv- 

ice, 

the service token (80) being stored in a mobile 
entity (20) associated with the user; and 
40 - subsequently detecting ([4]) a location match 
between the location of the user, as indicated 
by the location of said mobile entity (20), and a 
location indicated by said location data, and 
thereupon passing the service token (80) from 
4* the mobile entity (20) to a service provider sys- 

tem (40) to initiate delivery to the user of said 
particular service. 

2. A method according to claim 1 , wherein the service 
so token (80) includes communication address details 

of said service provider system (40). 

3. A method according to claim 2, wherein the service 
token (80) further includes a password for access- 

55 in g the service provider system (40). 

4. A method according to claim 1 , wherein the service 
token (80) includes both a service identifier and a 



40 



43 



9 



17 



EP 1 233 632 A1 



18 



user identifier, step (b) including a sub-step of the 
service provide system (40) checking the identity of 
the user of the mobile entity (20) against the user 
identity in the service token (80). 

5 

5. A method according to claim 1 , wherein the service 
token (80) includes user identity data and is digital- 
ly-signed by the party that carried out the qualifica- 
tion in step (a) whereby the service provider system 
(40) can check the authenticity of the data in the *<> 
token, the user mobile entity (20) having an associ- 
ated public-key / private-key pair and being required 

by the service provider system (40) in step (b) to 
authenticate its identity by using its private key to 
sign and return data proposed by the service pro- *s 
vider system (40). 

6. A method according to any one of the preceding 
claims, wherein service delivery in step (b) is con- 
ditional upon the user inputting a personal identify 20 
cation code. 

7. A method according to claim 1 , wherein the se rvice 
token (80) is digitally signed by the party that carries 
out the qualification in step (a), the service provider 
system (40) using this digital signing of the service 
token (BO)to check the origin and authenticity of the 
service token in step (b). 

8. A method according to claim 17 wherein the location 30 
data is stored in one of: 

a location server (67) of a cellular radio com- 
munications infrastructure (10) usable by the 
mobile entity (20), 35 
the mobile entity (20), 
the service provider system (40), 

where it is compared in step (b) against the current 
location of the mobile entity (20) as provided by one *o 
of: 

a location server (67) associated with said com- 
munications Infrastructure (10)usable by the 
mobile entity (20), 45 
location discovery means of the mobile entity 
(20); 

in order to detect a said location match. 

so 

9. A method according to claim 1 , wherein the location 
data is indicative of multiple locations. 

10. A method according to claim 1, wherein multiple 
service tokens (80) associated with different serv- 55 
ices to be delivered to the same user, are stored in 

a common repository. 



11 . A method according to claim 1 . wherein said service 
token . (80) specifies a particular number of times (in- 
cluding only once) that the associated service can 
be provided. 

12. A method according to any one of the preceding 
claims, wherein the service token (80) includes cus- 
tomisation data for customising a generic version of 
said particular service to the user. 

13. A service delivery system comprising: 

a mobile entity (20) associated with a user; 
a location- description repository (73) for storing 
location data (74); 

a service-token repository (76), incorporated 
into said mobile entity (20), for storing at least 
one service token (80); 

a qualification subsystem (72) for determining 
whether said user qualifies to benefit from an 
instance of a particular service, the qualification 
subsystem (72) being operative, upon deter- 
mining that a user is so qualified, both to store 
in the location repository (73) location data (74) 
indicative of at least one location where service 
delivery is to be triggered, and also to store in 
the service-token repository (75) a service to- 
ken (80) for said particular service; 
a service delivery subsystem (40) for providing 
said particular seivicerthe service deliverysub- 
system (40) being separate from said mobile 
entity (20): 

a communications arrangement (10) for ena- 
blingthe mobile entity (20)to communicate with 
the service delivery subsystem (40); 
a location-match subsystem (78) for detecting 
a location match between the location of the us- 
er, as indicated by the location of said mobile 
entity (20), and a location indicated by said lo- 
cation data (74); and 

a control arrangement responsive to the loca- 
tion-match subsystem (78) detecting a said lo- 
cation match to cause the mobile entity (20) to 
pass the service token (80) to the service de- 
livery subsystem (40) to initiate delivery of said 
particular service to the user. 

14. A system according to claim 13, wherein the loca- 
tion-description repository (73) is incorporated in 
said mobile entity {20) associated with the user. 

15. A system according to claim 1 3, wherein the servico 
token (80) includes customisation data for custom- 
ising a generic version of said particular service to 
the user. 
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